Objektorientierung - es gibt NUR Objekte

Ein System, das vorgibt, in objektorientierte Programmierung einzuführen, muß selbst objektorientiert aufgebaut sein. Diese Forderung ist eingehalten. Alles, was in der Delphi-Karel-Welt ist, sind Objekte und als solche ansprechbar. Deshalb wurde auch z. B. die Spur, die der Roboter ziehen kann, als Objekt angelegt und kann wie jedes Objekt auch wieder entfernt werden. Ebenso werden in den Container des Robots die aufgesammelten Objekte getan und können nach dem LIFO-Prinzip (stack) wieder heraus genommen werden.

Architektur / Design

Die Klassenhierarchie ist klassisch angelegt mit relativ tief gestaffelten Vererbungsketten. Wo die Situationen es erfordern, sind polymorphe Zugriffe vorhanden (Darstellung, Container).

Die Struktur der Klassen in Karel D. Robot ergibt sich aus der Sachlogik des Anwendungsproblems, nämlich dem Modell einer Welt mit Sachen und Lebewesen, wie im OOA-Modell dargestellt. Üblicherweise werden die so gefundenen Klassen dann ‚Fachklassen’ genannt, womit implizit unterstellt wird, daß sie kein Wissen über die Art und Weise ihrer Darstellung auf dem Bildschirm (View) haben und nicht an der Steuerung (Controller) durch die Entgegennahme von Events beteiligt sind.

Das Konzept der Trennung dieser drei Zuständigkeiten wird Model-View-Controller Pattern genannt und ist in Verbindung mit dem 4-Schichten-Modell das derzeit übliche Verfahren, um große Softwaresysteme zu strukturieren und entwerfen. DELPHI-Karel folgt diesem Prinzip teilweise nicht.
Die Idee war, verhaltensvollständige Objekte zu entwerfen, die selbst in der Lage sein sollten, sich dem Benutzer auf dem Bildschirm zu präsentieren. Das ist die alte Smalltalk-Idee, die meines Erachtens bei Anwendungen mit grafischen Objekten immer noch ihre Berechtigung hat und dabei durchaus Vorteile bietet. Insofern ist der Begriff der Fachklassen hier erweitert, als daß jedes Objekt per definitionem (TItem.Zeigen) seinen spezifischen View mitbringt (und daher auf das GUI zugreifen kann) und manipulierbar ist.

Die grafische Grundlage für DELPHI-Karel ist uGrafik, eine Sammlung von Klassen, die eben diesem Prinzip folgen. Daher ist die Implementation des Gesamtsystems vergleichsweise einfach und elegant zu lösen.
 

Zweiseitige Assoziationen

Wenn Objekte wie hier sich selbst darstellen sollen, muß ein Zugriff auf Systemkomponenten (Canvas usw.) organisiert werden, was in Fachklassen eigentlich nichts zu suchen hat. Das wird hier mit Hilfe der Grafik-Bibliothek uGrafik realisiert.

Die Welt registriert als übergeordnete Instanz die Anwesenheit aller Objekte, gleichzeitig benötigen die Objekte Informationen von der Welt. Da Delphi keine Zirkelbezüge in der Schnittstelle zuläßt, werden die erforderlichen Assoziationen im Implementation-Teil aufgebaut. In den Schnittstellen werden nur die Klassen importiert, die auch exportiert werden müssen.

Mehrere Roboter / Critters

Selbstverständlich können sich mehrere Exemplare 'gleichzeitig' in der Welt bewegen. In dieser Version ist jedoch keine echte Nebenläufigkeit eingebaut. Das hat zur Folge, daß ein Objekt seine Bewegung abgeschlossen haben muß, bevor das nächste startet. Da ein Weg 30 pix beträgt, ist das natürlich deutlich sichtbar. Ein Effekt, mit dem man aber das Problem der Nebenläufigkeit schön sichtbar machen kann.

Bildschirmauflösung - Darstellung

Unter Windows 2000 kommt es manchmal vor, daß die Zeichen 1..12 , A..N (Zeilen/Spalten) in einem zu kleinen Font dargestellt werden. --> F.A.Q

Version-Historie
 

2.4.1	25-AUG-05	Das ganze Paket in einen Installer eingebunden.
2.4	29-APR-05	Delphi-Karel Light durch Reduktion aus Version 2.4 extrahiert.